開發和部署安全服務和應用程式需要與許多內部和外部系統整合，例如：身份驗證和雲端儲存。
許多軟體開發都需要與越來越多的服務整合，這要求開發人員處理多個機敏資料。
例如：資料庫憑證，API Token，OAuth機敏資料等。

一旦將它們保存到設定文件中，它們經常會被放入雲端的版本控制系統中，進入攻擊者的手中。
機敏資料是出於某種原因而組成的，通常可以提供對許多資料，計算資源或權限帳戶的存取。
我們必須妥善處理機敏資料，確保我們限制機敏資料的使用範圍以及最小權限，並使意外洩漏的可能性降低。

問題範例

到Github的憑證洩漏是常見且麻煩的問題。
這可以使惡意行為者存取內部系統，資料，API等。
例如：在公開Web伺服器上意外地取得包含憑證的Script文件。

常見範例是授予自己"管理員"的權限，因此他們不必擔心確定自己所需的最低權限。
當這些憑證洩漏時，惡意參與者可以執行"管理員"可以做的任何事情。
例如：授予對該用戶可能是其成員的所有群組的存取權限。

這些小組有潛力跨越團隊，專案，客戶等。
當開發人員使用自己的 LDAP/Google 憑證來測試時，通常會看到這種情況。
儘管它很便利，但卻是一個壞習慣。

程式碼中常見的機敏資料（未加密）
- 原始 HTML 頁面
- 部署的 Javascript
- 公開 Github
- 公開 AWS Bucket
- 已部署的執行檔文件
- 部署的 Script
- 部落格貼文

所有內容除機敏資料管理員外，永遠不要在任何地方鍵入機敏資料。
混淆或替代(ROT-13、BASE-64編碼等）也不是保護機敏資料的有效方法。

機敏資料

機敏資料是可以用來進行身份驗證或授權的任何內容。

• 用戶密碼
• API Token
• TLS 證書

秘密也是任何機敏資料，敏感或個人身份訊息（PII）

• 信用卡
• 身分證號碼
• 護照號碼

最佳做法

常見範例：

• CI/CD Script
• 通過移動/網路應用存取雲端資源
• 後端的服務帳戶身份驗證
• 私鑰加密
• 傳輸加密（例如：HTTPS/TLS）

根據經驗，應該在每個機會中都使用臨時憑證。
並非所有系統都以支持此功能的方式建構，因此強烈建議使用管理工具，例如：AWS（Amazon Web Services）管理。
環境變量是可傳遞的，但不建議使用。
絕對不應該在程式碼中儲存機敏資料訊息。

保護機敏資料

在按照上述步驟準備好應用程式之後，請利用秘密管理基礎結構來安全地儲存和存取您的秘密。
Google Cloud KMS（金鑰管理服務）或Amazon AWS KMS中的雲端選項。

應用程式安全團隊擁有監視源程式碼資料庫中機敏資料的工具，但是該機制僅應為最後一道防線。

GCP：

在Google Cloud中進行應用程式身份驗證的最佳做法是使用服務帳戶。
不要將服務帳戶密碼儲存在應用程式源程式碼中，而應使用指向應用程式源程式碼外部的憑證（例如：保險櫃）的環境變量。
限制誰可以充當服務帳戶。
被授予服務帳戶"服務帳戶執行者"角色的用戶可以存取該服務帳戶有權存取的所有資源。

AWS：

AWS金鑰通常採用以下格式：

• ʻAWS_ACCESS_KEY_ID：AKIA ****************`
• ʻAWS_SECRET_ACCESS_KEY：SYU *************************************`

這些金鑰由AWS IAM（身份和存取管理）或AWS STS產生。

由IAM生成的金鑰：這些金鑰分配給IAM用戶（每個用戶最多2個金鑰），個人（人員）或服務帳戶（非人員）都可以使用。
但是，儘管這些金鑰可用於服務帳戶，但最佳實踐是盡可能利用STS生成臨時憑證，以供應用系統使用。

STS生成的金鑰：這些金鑰是臨時金鑰，預設情況下會在12小時（最少15分鐘，最大36小時）內失效。
建議以最短的持續時間生成這些金鑰。
受到破壞的金鑰很快對惡意行為者變得毫無用處。
開發人員通常會使用他們的個人存取金鑰，當有人離開公司並終止其帳戶時，這可能會導致意外中斷。
STS也避免了這種情況。

python
```
＃建立一個Session
session = boto3.Session（）

＃使用Session建立一個sts客戶端
sts = session.client（"sts"）

＃取得當前Session的臨時登入資料
token = sts.get_session_token（）['Credentials']
```

授予金鑰的存取權限受隨附的IAM策略（最小1，最大10）控制。
如果洩漏，則這些金鑰會立即授予對隨附IAM策略所允許的所有資源的全域存取權限。

為了安全，金鑰維護必須遵循以下條件：

• 切勿使用為單個用戶生成的金鑰；始終使用臨時STS金鑰，附加的IAM角色或服務帳戶（非人工IAM用戶）。
  這是為了確保在例如：個人在公司內部變動或離開公司
• 確保以最低權限建立策略。
  對於不同的實例，最好是建立具有較少權限的多個服務帳戶，而不是共享具有過多權限的單個帳戶。
• 盡可能使用STS Token。
  如果角色分配可用於您在AWS中使用的任何服務，則應使用IAM角色和STS來獲取臨時憑證。

證書洩漏

憑證洩漏很關鍵，因為它們通常會授予對系統的高級別存取權限，並可能導致資料和系統受損。

常見問題

在大多數情況下，開發/測試環境與開發環境幾乎相同。
一些情況下使用者又共享環境，從而增加了攻擊者橫向移動的風險。

除了對基礎架構的直接風險外，現在這些秘密本身還儲存在代管程式碼的伺服器以及任何複製或分支的程式碼的人的所有開發人員工作站上。
假設應該是公開的秘密，因為僅限於沒有辦法追踪它們的傳播。

當然，與個人密碼一樣，我們經常會遇到重用的情況。
因此，您的登入機敏資料與生產機敏資料相同。

我的測試程式碼如何？

如果測試程式碼利用"虛擬"憑證來測試解析程式碼或錯誤處理。
這些"虛擬"憑證用於針對本地或臨時模擬進行測試。
而"永久性"測試設施存在著有與開發/測試環境中相同的問題。

參考資料

• 紅隊資料
  • https://github.com/yeyintminthuhtut/Awesome-Red-Teaming
• AWS資料
  • 管理AWS存取金鑰的最佳實踐：https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best- practices.html
  • 使用AWS Secrets Manager：https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html
• GCP資料
  • 服務帳戶：https://cloud.google.com/iam/docs/understanding- service- accounts
  • 環境變數：https://cloud.google.com/functions/docs/env-var